\section{Future Work} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\label{sec:fw}

Using a library implementation was essential for experimentation and for being able to
test our ideas on multiple production-quality compiler systems.
However, now we hope to re-implement our ideas in a compiler.
This would allow us to improve further surface syntax, diagnostics, and performance.

In the nearest future, we would like to make our library to be safe and efficient 
in a multi-threaded environment. Currently it relies heavily on static variables 
and global state, which will have problems in a multi-threaded environment. 

The match statement that we presented here deals with only one subject at the 
moment, but we believe that our memoization device, along with the vtable pointer memoization 
technique we presented, can cope reasonably efficiently with multiple subjects. 
Their support will make our library more general by addressing asymmetric 
multiple dispatch.

We would also like to experiment with other kinds of cache indexing functions in 
order to decrease the frequency of conflicts, especially those coming from the use 
of dynamically-linked libraries.

Containers as described by the standard C++ library do not have the implicit 
recursive structure present in lists, sequences and other recursive data 
structures of functional languages. Viewing them as such with view will likely 
have a significant performance overhead, not usually affordable in the kind of 
applications C++ is used for. We therefore would like to experiment with some 
pattern matching alternatives that will let us work with STL containers 
efficiently yet expressively as in functional languages.
%
%Last but not least we would like to look at providing support for alternative 
%matching semantics.
%
%